Lesson Contents

This lesson explains how to use OSPF as the PE-CE routing protocol for MPLS L3 VPN. The configuration is very similar to PE-CE RIP or PE-CE EIGRP but OSPF has some extra options as a link-state routing protocol.

The first part is about configuring LDP, VRFs and iBGP between the PE routers. This is the same as my previous lessons so you might want to skip to the PE-CE OSPF section.

Here’s the topology we will use:

Above we have 5 routers. CE and CE2 belong to the customer who wants to run OSPF between their sites. The service provider has two PE routers and one P router in the middle.

Let’s prepare the service provider routers. We need an IGP (OSPF) and LDP on the PE1, PE2 and P router.

Now we can configure OSPF for routing in the service provider network:

This takes care of IGP and LDP. Make sure you have LDP neighbors before we continue:

Our P router in the middle has two neighbors so this is looking good. Just in case, let’s verify if there is connectivity between PE1 and PE2:

The PE routers are able to reach each others loopback interfaces and we are using label switching.

Our next step in the configuration is to configure the VRFs. I will use a VRF called “CUSTOMER”, the route distinguisher and route-target will be 1:1.

Don’t forget to add the interfaces facing the customer routers into the VRF:

Let’s check if the PE routers are able to ping the CE routers from the VRF:

So far so good…

Our two PE routers require iBGP to exchange the VPNv4 routes. Let’s configure this:

Before we continue we should check if our routers have formed an IBGP neighbor adjacency:

Great, the BGP session has been established.

Now we can work on OSPF between the PE and CE routers. Let’s start with CE1 and CE2 first:

Each CE router has a loopback which is advertised in OSPF. Now we can configure OSPF on the PE routers for the customer VRF:

Unlike RIP or EIGRP, we don’t use an address-family but a different process for a VRF. Let’s see if we have learned anything:

Great, our PE routers learned the loopback interfaces from the CE routers. Let’s redistribute this into BGP:

If everything went ok, we should now have some VPNv4 routes:

Exellent, we have VPNv4 routes. You can also see that the metric from OSPF (cost 2) has been saved in the BGP MED attribute. Now let’s redistribute these VPNv4 routes back into OSPF:

Our configuration is now complete.

First we’ll check if we have connectivity between our CE routers. Did they learn anything?

Our CE routers have learned each others networks. There’s something interesting in the output above…normally when we redistribute something into OSPF then our prefixes show up as O E2 or E1, now we seem to have O IA prefixes. I’ll explain why in a bit, first let’s see if we have connectivity:

Our two CE routers are able to reach each other, let’s try a trace as well:

Everything seems to be working, the CE routers are able to reach each other and above you can see the transport label (17) and VPN label (16).

There’s a couple of things left I’d like to explain however, let’s think about the prefixes that we have seen on the CE routers.

Our CE routers advertise routes to the PE routers who redistribute it into BGP so they become VPNv4 routes. These VPNv4 routes are exchanged from one PE router to another. Once a PE router receives a VPNv4 route and redistributes it into OSPF, how does it know what LSA type to use and to what area the prefix belongs? Also, how is it possible that redistributed routes show up as inter-area routes?

OSPF works a bit different when we use it as the PE-CE routing protocol, I’ll give you the short version here but if you want to know all details you can check RFC 4577.

Both of our customer sites are using OSPF area 0, normally it’s impossible to have two backbone areas unless you connect them to each other with a virtual link. When we use MPLS L3 VPN, the service provider network is seen by OSPF as the superbackbone: